Method and apparatus for filtering electronic messages

ABSTRACT

A method is provided for filtering electronic messages such as unsolicited bulk email. The method includes establishing a communications connection with the remote server under the Simple Email Transfer Protocol or other suitable protocol; accepting session data from the remote server; and determining if the session data meets criteria associated with legitimate messages. If the data pertaining to the connection does not meet the criteria associated with legitimate messages, then one or more stimulus signals are sent to the remote server. If the server responds to the stimulus signal in the manner required by the communications protocol, then the session can be added to a database of known sessions. The session is then terminated by responding to the server with a temporary error message in accordance with the protocol. If the remote server is a legitimate server complying with the STMP, it will resend the message after a prescribed time period.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. patent application Ser. No.11/514,658, filed Sep. 1, 2006, which is incorporated herein in itsentirety by reference.

TECHNICAL FIELD

The present invention relates to the field of electronic messaginggenerally and in particular to methods for filtering unsolicited email.

BACKGROUND

Email over the Internet and other networks have become a mainstay ofbusiness and personal communications. Email over the Internet istypically sent using the Simple Mail Transfer Protocol (“SMTP”), apopular text based mail transport and delivery protocol. SMTP is definedin The Internet Society Request of Comment (“RFC”) No. 2821 (April2001), which is hereby incorporated by reference.

SMTP contemplates that transmission of emails occurs from a sendinguser's host (or “originating server”) to the receiving user's host (or“receiving server”) when the two hosts are connected to the same networksuch as the Internet or other transport service or connected todifferent networks coupled by a gateway.

Under SMTP, the sending and receiving servers establish a communicationsconnection over the transport service. Then, the originating server(sometimes referred to herein as the remote server) initiates a mailtransaction, which includes commands to specify certain informationabout the session, including the originator and destination of the mail.This information is referred to as the “envelope.” Next the originatingserver sends a command to transmit the message content itself. Themessage content is composed of a header and a body. The header includesstructured field/value pairs. The body is the actual message which canbe formatted in accordance with MIME, for example.

The receiving server responds to each command with a reply. For example,replies indicate that the command was accepted or that a temporary orpermanent error condition exists. Replies include three digit codes(such as “250”).

Unsolicited bulk email (“UBE”), popularly known as “spam,” is a growingproblem for email users. Spam clogs users' inboxes, wastes networkbandwidth, consumes human and machine resources to evaluate and discard,and often is used to disseminate malicious code or perpetrate fraud orother unlawful or undesirable activity.

A number of approaches have been proposed to address the problem of UBE.One approach is to assess the content incoming email and to filter outmessages with certain content associated with UBE. However, sendersquickly adapt content to circumvent these systems. In response, evermore aggressive content filters may be utilized. However, this leads tofalse positives—that is, legitimate emails that are flagged or filteredas UBE.

When legitimate emails are filtered as UBE, users do not receivepotentially important communications. To mitigate this risk, filteredUBE can be placed into a quarantine for periodic review by the user.However, this consumes human and machine resources and can delay receiptof an urgent legitimate email that is mistakenly filtered as UBE placeinto quarantine.

Another approach is to post suspect UBE senders on a deny list. However,spenders of spam will frequently change servers, sometimes hijackingotherwise legitimate systems. This counter-tactic limits theeffectiveness of the deny list.

Another approach that has been adopted is the challenge response system,in which the recipient mail server sends a challenge to unknown mailsender and quarantines the sender's mail until the sender provides anappropriate response to the challenge. A drawback to this system is thatit imposes delay and inconvenience on legitimate but unknown senders.Also, if a legitimate sender does not for whatever reason respond to thechallenge, then the incoming email will not be received.

It would be desirable to more completely filter UBE while avoidingmistakenly filtering legitimate email. As used in this application, theterm “legitimate” means a message other than UBE or other types of bulkemail that are either prohibited by law or that are communications thatcomputer users generally do not wish to receive. The term “legitimate”as applied to a sender or connection means a sender or connection notengaged in sending UBE.

SUMMARY OF THE INVENTION

Embodiments of a method for processing an email message having messagecontent and sent by a remote server in accordance with a communicationsprotocol are taught herein. In one such embodiment, a method includesestablishing a communications connection with the remote server andexchanging a plurality of session messages defining a communicationssession with the remote server, at least some of which are separate fromthe message content. The method further includes accepting from theremote server session data pertaining to the communications connection,including information pertaining to at least one of the following: theremote server, the sender of the email message, and the destination ofthe email message. The behavior of the remote server is tested togenerate a machine-originated response from the remote server inaccordance with the communications protocol to determine if the remoteserver is operating in accordance with the communications protocol. Thetesting is initiated during the communications session. Thecommunications connection can be processed in response to whether theremote server is operating in accordance with the communicationsprotocol.

Embodiments of an apparatus for processing an email message havingmessage content and sent by a remote server in accordance with acommunications protocol are taught herein. In one such embodiment, anapparatus includes a communications port adapted for establishing acommunications connection with the remote server. The apparatus alsoincludes a processor coupled to the communications port and adapted toestablish a communications connection with the remote server andexchange a plurality of session messages defining a communicationssession with the remote server, at least some of which are separate fromthe message content. The processor is also adapted to accept from theremote server session data pertaining to the communications connection,including information pertaining to at least one of the following: theremote server, the sender of the email message, and the destination ofthe email message. Further, the processor is adapted to test thebehavior of the remote server to generate a machine-originated responsefrom the remote server in accordance with the communications protocol todetermine if the remote server is operating in accordance with thecommunications protocol. The testing is initiated during thecommunications session. The processor is adapted to process thecommunications connection in response to whether the remote server isoperating in accordance with the communications protocol.

Embodiments of a system for processing an email message are also taughtherein. In one such embodiment, a system includes a communicationsnetwork, a remote server and a receiving server. The remote server isconnected to the communications network and adapted to send the emailmessage in accordance with a communications protocol. The receivingserver connected to the communications network and adapted to exchange aplurality of session messages containing session data and defining acommunications session with the remote server. The receiving serverincludes a connection assessment module and a connection behaviortesting module. The connection assessment module is adapted to assessthe session data. The connection behavior testing module is adapted totest the behavior of the remote server during the communications sessionto generate a machine-originated response from the remote server inaccordance with the communications protocol to determine if the remoteserver is operating in accordance with the communications protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

The description herein makes reference to the accompanying drawingswherein like reference numerals refer to like parts throughout theseveral views, and wherein:

FIG. 1 is a block diagram of an email system in which embodiments of thepresent invention are implemented.

FIG. 2 is a block diagram illustrating in greater detail a filteringmodule for use in the email system shown in FIG. 1.

FIG. 3 is a flow chart of the operation of the filtering module of FIG.2 in accordance with a first embodiment of the invention;

FIG. 4 is a flow chart of the operation of the filtering module of FIG.2 in accordance with a second embodiment of the invention;

FIG. 5 is a flow chart of the operation of the filtering module of FIG.2 in accordance with a third embodiment of the invention;

FIG. 6 is a block diagram of an email system in accordance with a fourthembodiment of the invention; and

FIG. 7 is a block diagram of an email system in accordance with a fifthembodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Referring to FIG. 1, an email system 10 is illustrated in whichembodiments of the present invention are implemented. Email system 10includes a receiving host 12 and an originating server 14 incommunications via the public Internet 16 to transfer email using SMTP.The disclosed embodiments can be implemented using any suitablemessaging protocol and is not limited to email or SMTP. The disclosedembodiments can also be implemented over any suitable type of networkand are not limited to use with the public Internet.

Receiving host 12 includes an receiving server 18 coupled to a filesystem 20 and a mailbox 22. Other configurations for receiving host 12are possible and ancillary equipment and software such as firewalls havebeen omitted for ease of understanding the invention. A desktop emailclient 24 such as Microsoft Outlook™ is coupled to the mailbox.Originating host 14 includes a remote or originating server 26 that iscoupled to a file system 28. With respect to its outgoing emailcommunications, originating server 26 is sometimes referred to as theclient in the SMTP specifications.

In accordance with SMTP, originating server 26 on host 14 initiates aconnection with server 18 on host 12 for purposes of transmitting one ormore emails in the course of a communications session. Thecommunications session includes a series of commands issued byoriginating server 26 and replies issued by receiving server 18. Thefollowing table illustrates a simplified session between a receivingserver (“S”) and an originating server (“C”):

TABLE ONE S: 220 www.foo.com ESMTP Postfix C: HELLO target.com S: 250Hello target.com C: MAIL FROM: <sender@target.com> S: 250 Ok C: RCPT TO:<recipient@foo.com> S: 250 Ok C: DATA S: 354 End data with<CR><LF>.<CR><LF> C: Subject: test message C: From: sender@target.com C:To: recipient@foo.com C: C: Test data. C: . S: 250 Ok: queued as 12345C: QUIT S: 221

In each session, the originating server 26 transmits data thatinitiates, constitutes or otherwise pertains to the session itselfbefore transmitting the message content. This session information, alsoknown as session data, can be contained in the message envelopes or canbe information derived from the syntax, order or context of the sessioncommands transmitted by the originating server. For example, sessioninformation can include the IP address of the originating server,envelope sender of the message, and the envelope destination of themessage. Part of this information is typically placed in a messageenvelope. After receiving and processing the envelope, the server 18receives the message content, which comprises a header section and abody.

It is desired to filter UBE and other unauthorized messages that aresent to receiving host 12. Referring to FIG. 2, a filtering system 30which resides on SMTP server 18 filters incoming SMTP sessions totemporarily reject UBE and other unauthorized messages. As will beexplained below, temporary rejection of messages can occur after theenvelope is received but before the message content is transferred tothe receiving hosts. For ease of illustration, filtering module 30 isdisclosed herein as software implemented only on SMTP server 18.However, the programming logic of filtering module 30 can be distributedover more than one computer or implemented in hardware if desired.

Filtering system 30 includes a connection assessment module 32, acontext assessment module 34 and a connection behavior testing module36. Connection assessment module 32 and context assessment module 34assesses the data pertaining to the session for new connections todetermine whether that data meets criteria associated with legitimateemail. These criteria are discussed below in detail, but generallyspeaking can include primary criteria (which if met mean that aconnection is legitimate and will be accepted) and secondary criteria(which if met mean that a connection is possibly legitimate but will notat this time be accepted; instead information about the connection willbe recorded for use in future sessions involving the same originatingserver and sender).

Connection assessment module 32 is in communications with a database 38which includes information about known connections including historicaltransactions with known connections. Database 38 can reside locally onreceiving host 12 or can be hosted remotely and can include informationgathered by receiving host 12 or by multiple hosts. Database 38 can be asingle database or can be distributed in different physical databases.Connection assessment module 32 assesses the information in the envelopeto determine whether the connection is a priority connection or at leasta known connection. A priority connection is a connection identified indatabase 38 as legitimate. Priority connections can be identified in thedatabase by the IP address of the originating server, the envelopesender, the envelope destination or a combination of all three.

A “known” connection is a connection that has similar characteristics asconnections previously established with the receiving server 18. Suchsimilar characteristics can include the IP address of the originatingserver, envelope sender, envelope destination, subnet for theoriginating server 26. Once connection assessment module 32 identifies aconnection as being known, it can query database 38 for historicaltransaction data involving the connection to determine if the connectionis legitimate. This historical transaction data can include for examplethe number of previous times that the connection has attempted delivery.If the number of attempted deliveries exceeds a predetermined threshold(such as three for example), then the connection can be considered bothknown and legitimate. Other historical data that can be used to validatea connection includes the amount of time that has elapsed since theconnection was last established with the destination server or with anyserver belonging to a given set of destination servers, with longer timeperiods indicative of non-UBE messages.

Connection assessment module 32 can use other criteria to determine if aconnection is priority, known or otherwise legitimate. Criteria shouldbe selected that are associated with legitimate messages.

Context assessment module 34 can be applied to previously unknownconnections. Context assessment module 34 can also coupled to database38 as well as external resources 40. Context assessment module 34applies additional inquiries or criteria based on information other thanthe data pertaining to the connection that is transmitted by theoriginating server. These contextual inquiries can include:

-   -   is the remote server on only one black list? [−1 if yes]    -   is the remote server on more than one black list? [−3 if yes]    -   is the remote server on a local whitelist? [+5 if yes]    -   has the remote server attempted delivery of an email to a large        number of different destinations over a short period of time?        [−2 if yes]    -   is the remote server not allowed to send emails as part of the        domain specified in the envelop sender? [−5 if yes]    -   does the reverse DNS of the remote server match the sender        information in the envelope? [+1 if yes, −1 if no]    -   is the remote server known on the local server as a server with        which connections are often established? [+2 of yes]

A heuristic approach can be used for assessing context. For example,each inquiry or criteria can be assigned a given weight (as illustratedin brackets above) and an overall context assessment score can becomputed adding up the resulting scores. If the context assessmentachieves a predetermined minimum score (such as 6 using the weightingsillustrated above), the context of the connection is deemed favorable.Otherwise, the context is deemed unfavorable. Other suitable scoringschemes and algorithms can be used.

Behavior testing module 36 can be applied to those connections who areneither priority or known and that have either favorable or unfavorablecontexts. Behavior testing module generates a reply or other stimulussignal which is transmitted to the originating server to determinewhether the originating server will respond in the manner required bySMTP or the applicable protocol under which the message has beentransmitted.

To comply with SMTP or other protocol requires time and resources.Senders of UBE and other unauthorized messages are motivated to sendmany millions of messages as cheaply and quickly as possible, andaccordingly they do not choose to expend the time and resources requiredto comply with the protocol.

If an originating server complies with the applicable protocol, it ismore likely to be operated by a legitimate sender of email (as opposedto a spammer) and accordingly the message is likely to be legitimate. Onthe other hand, if the originating server does not comply with theapplicable protocol, it is more likely a spammer and accordingly themessage is likely to be UBE or other unauthorized email.

Various stimulus signals may be employed, including: transmittingqueries that are not frequently used; transmitting a reply after a delayof at ten to thirty seconds or more since the originating server'scommand is received; transmitting a reply that requires the originatingserver to send messages one at a time; and not accepting commands thatare transmitted in the wrong order.

More than one stimulus signal can be used. Other suitable stimulussignals can be used. Information about how the originating server 26responds to the stimulus signal or signals can be added to database 38.For example, if originating server 26 responds to the stimulus signal orsignals in accordance with SMTP or other applicable protocol, then theconnection can be added to database 38 as a known connection.

Referring to FIG. 3, the operation of filtering system 30 is illustratedin accordance with a first embodiment. Beginning at block 42, aconnection is established over the Internet between originating server26 and receiving server 18. At block 44, originating server 26 sends andreceiving server 18 receives session data. At block 46, the receivingserver 18 uses the filtering system 30 to assess the session data. Asillustrated in block 48, this assessment will include queries todatabase 38 as well as other external resources (not shown in FIG. 3).

As explained above, the assessment of session data can be made usingeither or both of connection assessment module 32 and context assessmentmodule 34. The objective of the assessment is to apply to the sessiondata one or more tests or other criteria that are associated with theauthentic messages. For example, connection assessment module 32 candetermine if the connection is a priority connection. Context assessmentmodule 34 can apply additional tests or criteria to previously unknownconnections, such determining whether the remote server is on a blacklist. The invention is not limited to specific tests or criteria thatmake use of session data. Other appropriate tests and criteria willoccur to those skilled in the art of electronic messages and these canbe used as well.

At decision block 50, a determination is made as to whether the sessiondata has met the applicable tests or other criteria to conclude that theconnection is legitimate. If the session data has met the test or othercriteria, then control moves to block 52, where the filtering system 30accepts the message content. If the session data does not meet the testor other criteria, then control moves to block 54, where connectionbehavior testing module 36 sends a stimulus to originating server 26 todetermine if originating server 26 is compliant with SMTP or otherapplicable protocol.

At decision block 56, a determination is made as to whether the behaviorof sending server 26 is compliant with SMTP or other applicableprotocol. If the behavior is compliant, control moves to block 58, wheredatabase 38 is updated with information about the connection. Forexample, the connection may be indicated as a “known” or “priority”connection in database 38. Control then moves to block 52, where thefiltering system 30 accepts the message content.

If at block 56 it is determined that the behavior of originating server26 is not compliant with SMTP or the applicable standard, then controlmoves to block 60, where the session is temporarily rejected. Rejectioncan be accomplished by sending a reply to the originating server 26 thatindicates the occurrence of a temporary error or other problem at thereceiving server 18 and can request the originating server 26 to resendthe message. For example, with the SMTP protocol a 4xx reply may besent.

A temporary error reply is in effect another means of testing behaviorof the originating server. Servers that send UBE or other unauthorizedmessages typically do not comply with requirements under SMTP or otherprotocols to resend messages after receiving a temporary error response.Thus, UBE or other unauthorized messages will likely not be resent, thusreducing spam. However, legitimate messages from legitimate sources arelikely to be resent. Alternatively, at block 60, the session can berejected a non-temporary basis.

At block 60, database 38 can be updated with information from theenvelope of the rejected connection, which can be deemed as “known” evenif rejected. Because spammers are unlikely to reestablish theconnection, the database may accumulate a large number of connectionsthat have been seen only once or seen multiple times, but only during asingle, short time period such as an hour for example. These one-timeconnections can be periodically purged from the database. Alternatively,they can be removed if they were last seen more than, for example,twelve months ago.

Referring to FIG. 4, the operation of filtering system 30 is illustratedin accordance with a second embodiment. Beginning at block 62, aconnection is established over the Internet between originating server26 and receiving server 18. At block 64, originating server 26 sends andreceiving server 18 receives session data. At block 66, the receivingserver 18 uses the filtering system 30 to assess the session data. Asillustrated in block 68, this assessment will include queries todatabase 38 as well as other external resources (not shown in FIG. 4).

As explained above, the assessment of session data at block 66 can bemade using either or both of connection assessment module 32 and contextassessment module 34. The objective of the assessment is to apply to thesession data one or more tests or other criteria that are associatedwith the authentic messages. For example, connection assessment module32 can determine if the connection is a priority connection. Contextassessment module 34 can apply additional tests or criteria topreviously unknown connections, such determining whether the remoteserver is on a black list. The invention is not limited to specifictests or criteria that make use of session data. Other appropriate testsand criteria will occur to those skilled in the art of electronicmessages and these can be used as well.

The tests and criteria that are applied at decision block 66 can beplaced into two or more groups including primary criteria and secondarycriteria. Primary criteria are tests or other criteria which, if met,indicate that the connection is authorized or otherwise legitimate. Forexample, a primary criteria can be that the connection is a priorityconnection on database 38. Another primary criteria can be that theconnection is known and that the historical transaction data for theconnection indicates that it is legitimate.

Secondary criteria are tests or other criteria which if met indicate apossibility that a connection is authorized. For example a secondarycriteria can be that a connection is known (but is not associated withhistorical transaction data indicating legitimacy) based on the contentof database 38. Another secondary criteria can be that the connection,if not known, at least has a favorable context as determined by contextassessment module 34.

At decision block 70, a determination is made as to whether the sessiondata has met the applicable primary criteria. If the session data hasmet primary criteria, then control moves to block 72, where thefiltering system 30 accepts the message content. If the session datadoes not meet the primary criteria, then control moves to decision block74, where determination is made as to whether the session data meets thesecondary criteria. If the session data has met the secondary criteria,then control moves to block 76 where database 38 is updated withinformation about the connection. For example, the connection may beindicated as a “known” or “priority” connection in database 38. Controlthen moves to block 78 where filtering system 30 rejects the connectionas described below.

If at decision block 74 it is determined that the session data has notmet the secondary criteria, then control moves to block 80, whereconnection behavior testing module 36 sends one or more stimulus signalsto originating server 26 to determine if originating server 26 iscompliant with SMTP or other applicable protocol. At decision block 82,a determination is made as to whether the behavior of sending server 26is compliant with SMTP or other applicable protocol. If the behavior iscompliant, control moves to block 76, where database 38 is updated withinformation about the connection. For example, the connection may beindicated as a “known” or “priority” connection in database 38. Controlthen moves to block 78, where filtering system 30 rejects the connectionas described below.

At block 78, rejection can be accomplished on a temporary-basis bysending a reply to the originating server 26 that indicates theoccurrence of a temporary error or other problem at the receiving server18 and can require the originating server 26 to resend the message asexplained above. Alternatively, rejection at block 78 can be on anon-temporary basis. Note that if database 38 is updated at block 76 forconnections that have not meet the primary or secondary criteria, thenthe database may accumulate a large number of connections from spammers.The one-time connections can be periodically purged from the database asdescribed above.

In effect, the application of primary and secondary criteria divideconnections into three categories of trust levels: (1) those connectionsthat have sufficient indications of legitimacy (i.e., meet the primarycriteria) and are therefore considered legitimate; (2) those connectionsthat have intermediate indications of legitimacy (i.e., meet thesecondary criteria but not the primary criteria) and are thereforeconsidered possibly legitimate; and (3) those connections that haveinsufficient indications of legitimacy (i.e. do not meet the primary orsecondary criteria) and are therefore considered suspect. Legitimateconnections are accepted. Connections that are possibly legitimate areposted to the database (step 76) and then temporarily rejected (step78). The filtering system 30 can be programmed so that it is more likelyto treat such connections as being legitimate if they are re-establishedfollowing rejection. Connections whose legitimacy is suspect aresubjected to testing by connection behavior testing module 36 (step 80).If the behavior test indicate compliance with the protocol, then theconnections are treated as possibly legitimate and posted to thedatabase (step 76) and then temporarily rejected (step 78).

Connections can be divided up into more granular categories of trust byincreasing the number of classes of criteria that are applied, such asprimary, secondary and tertiary.

Referring to FIG. 5, the operation of filtering system 30 is illustratedin accordance with a third embodiment. Beginning at block 84, aconnection is established over the Internet between originating server26 and receiving server 18. At block 85, originating server 26 sends andreceiving server 18 receives session data. At block 86, the receivingserver 18 uses the filtering system 30 to assess the session data. Thisassessment can include queries to database 38 as well as other externalresources (not shown in FIG. 5).

Specifically, connection assessment module 32 determines if theconnection is a priority connection or a known connection. At decisionblock 88, if the connection is a priority connection, then control movesto block 90, where the filtering system 30 accepts the message content.If the connection is not a priority connection, then control moves todecision block 92. At decision block 92, if the connection is a knownconnection, then control moves to block 94. At block 94, connectionassessment module 32 can query database 38 for historical transactiondata involving the connection to determine if the connection islegitimate. This historical transaction data can include for example thenumber of previous times that the connection has attempted delivery. Ifthe number of attempted deliveries exceeds a predetermined threshold(such as three for example), then the connection can be considered bothknown and legitimate. Other historical data that can be used to validatea connection includes the amount of time that has elapsed since theconnection was last established, with longer time periods indicative ofnon-UBE messages.

At decision block 96, if the connection is considered legitimate, thencontrol moves to block 90, where filtering system 30 accepts the messagecontent. If the connection is not considered legitimate, then controlmoves to block 98, where filtering system 30 updates database 38 withinformation about the connection. Depending on the specific algorithmused to determine if a known connection is legitimate, the accumulationof historical transaction data in database 38 can increase the chancesthat filtering system 30 will conclude that a connection is legitimate.For example, a known connection can be considered legitimate if deliveryis attempted N times, where N is a predetermined number between 1 and 4.Control then moves to block 100, where filtering system 30 temporarilyrejects the connection.

Referring back to decision block 92, if the connection is not a knownconnection, then control moves to block 102, where connection contextassessment module can assess previously unknown connections. Contextassessment module 34 applies additional tests or other criteria todetermine if the context of the connection is favorable, as explainedabove. Context assessment module 34 can also be coupled to database 38as well as to external resources 40.

At decision block 104, if the context of the connection is favorable,control moves to block 106, where filtering system 30 updates database38 with information about the connection, including adding theconnection to the list of known connection.

Referring back to decision block 104, if context assessment module 34determines that the context of the connection is not favorable, thencontrol moves to block 108, where connection behavior testing module 36sends a stimulus to originating server 26 to determine if originatingserver 26 is compliant with SMTP or other applicable protocol.

At decision block 110, if behavior testing module 36 determines that thebehavior of sending server 26 is compliant with SMTP or other applicableprotocol, then control moves to block 106, where database 38 is updatedwith information about the connection, including adding the connectionto the list of known connection. If behavior testing module 36determines that the behavior of sending server 26 is not compliant withSMTP or other applicable protocol, then control moves to block 100,where filtering system 30 temporarily rejects the connection.

Because database 38 is updated at block 106, if the connection isre-established in the future, it will be identified as a knownconnection at block 92 and potentially accepted if connection assessmentmodule 32 determines that the connection is legitimate (block 96). Otherinformation about the connection can be recorded in database 38 anddepending on the specific algorithm used to determine if a knownconnection is legitimate, the accumulation of that historicaltransaction data in database 38 can increase the chances that filteringsystem 30 will conclude that a connection is legitimate in a futurecommunications session.

After processing at block 106, control moves to block 100, where thefiltering system 30 temporarily rejects the connection by sending areply to the originating server 26 that indicates the occurrence of atemporary error or other problem at the receiving server 18 and canrequire (in accordance with the applicable protocol) that theoriginating server 26 resend the message as explained above. Althoughthe protocol requires the sender to resend the message, sender of UBEoften ignore such requirements.

Note that if a connection meets certain primary criteria (such as beinga priority connection at decision block 88 or being a known andlegitimate connection at decision block 96), then the connection isconsidered authentic and is accepted. If a connection does not meetthese primary criteria but meets certain secondary criteria (such as atleast being known or having a favorable context) then information aboutthe connection is added to database 38 (at blocks 98 and 106),increasing the probability that it will be accepted in a future session.If the connection does not meet either the primary or secondarycriteria, then the connection is rejected. However, before rejecting theconnection, behavior testing module 36 tests the behavior of theoriginating server 26, and if the originating server 26 behaves inaccordance with the applicable protocol, then information about theconnection is added to the database 38 (at block 106).

Referring to FIG. 6 a block diagram of an email system 10′ illustratedin accordance with a fourth embodiment of the invention. Email system10′ includes a receiving host 14′. Incoming STMP connections 111 areredirected from email system 10′ to a server separate server on which afiltering system 30′ resides. Filtering system 30′ is substantiallyidentical to filtering system 30 described above. Filtering system 30′accepts legitimate email in accordance with the first through thirdembodiments described above and then forwards those accepted emails tothe receiving host 14′.

Referring to FIG. 7, a block diagram of an email system 112 illustratedin accordance with a fourth embodiment of the invention. A filteringsystem 30″ can be part of a larger system 112 for processing incomingmessages. Filtering system 30″ is substantially identical to filteringsystem 30 described above. Larger system 112 includes a virus filteringmodule 114, a content filtering module 116, an archive module 118 and astore and forward module 120. Virus filtering module 114 and contentfiltering module 116 are coupled to quarantines 122 to store suspectmessages. Archive module 118 is coupled to backup data storage 124 tohold archived messages. Larger system 112 can be implemented on incomingserver 18.

When filtering system 30″ is used in larger system 112, it can be placedat the front end to filter out incoming suspect incoming email messagesbased on session data without the requirement of receiving andprocessing message content. Because connections bearing suspect messagescan be temporally rejected, legitimate senders will attempt futuredelivery of legitimate messages.

The filtering system 30″ can provide processing efficiencies byrejecting suspect messages based on session data because computationallyexpensive processing of message content can be avoided. Also, becausethe content of suspect emails is not received, storage demands arereduced.

Also, the above-mentioned embodiments have been described in order toallow easy understanding of the present invention, and do not limit thepresent invention. On the contrary, the invention is intended to covervarious modifications and equivalent arrangements included within thespirit and scope of the appended claims, which scope is to be accordedthe broadest interpretation so as to encompass all such modificationsand equivalent structures as is permitted under the law.

1. A method for processing an email message having message content andsent by a remote server in accordance with a communications protocol,the method comprising: establishing a communications connection with theremote server; exchanging a plurality of session messages defining acommunications session with the remote server, at least some of whichare separate from the message content; accepting from the remote serversession data pertaining to the communications connection, includinginformation pertaining to at least one of the following: the remoteserver, the sender of the email message, and the destination of theemail message; testing the behavior of the remote server to generate amachine-originated response from the remote server in accordance withthe communications protocol to determine if the remote server isoperating in accordance with the communications protocol, the testinginitiated during the communications session; and processing thecommunications connection in response to whether the remote server isoperating in accordance with the communications protocol.
 2. The methodof claim 1, wherein testing the behavior includes sending at least onestimulus signal to the remote server.
 3. The method of claim 2, whereinthe step of processing the communications connection includes acceptingthe message content if the remote server responds to the stimulus signalin the manner required by the communications protocol.
 4. The method ofclaim 2, wherein the at least one stimulus signal is one of a commandand a reply, the format and content of which are specified by thecommunications protocol.
 5. The method of claim 2, wherein the at leastone stimulus signal does not comply with the protocol in terms of atleast one of timing, format and content.
 6. The method of claim 1,further comprising, exchanging a plurality of session messages definingthe communications session, at least some of which are separate from themessage content.
 7. The method of claim 6, wherein testing the behaviorincludes waiting a predetermined amount of time after receiving at leastone of the plurality of session messages from the remote server beforesending a stimulus signal to the remote server.
 8. The method of claim6, wherein testing the behavior includes terminating the communicationssession when at least one of the plurality of session messages from theremote server are transmitted in the wrong order.
 9. The method of claim1, wherein the communications protocol is the Simple Mail TransportProtocol.
 10. The method of claim 1, wherein testing the behaviorincludes terminating the communications connection.
 11. The method ofclaim 1, wherein processing the communications connection includesaccepting the message content when the remote server behaves in themanner required by the communications protocol.
 12. The method of claim1, wherein testing the behavior of the remote server comprises: sendingto the remote server at least one session message, the format andcontent of which are specified by the communications protocol, whereinthe session message is configured to generate a machine-originatedresponse from the remote server in accordance with the communicationsprotocol; and determining whether the remote server responds to thesession message in accordance with the communications protocol.
 13. Anapparatus for processing an email message having message content andsent by a remote server in accordance with a communications protocol,comprising: a communications port adapted for establishing acommunications connection with the remote server; a processor coupled tothe communications port and adapted to: establish a communicationsconnection with the remote server; exchange a plurality of sessionmessages defining a communications session with the remote server, atleast some of which are separate from the message content; accept fromthe remote server session data pertaining to the communicationsconnection, including information pertaining to at least one of thefollowing: the remote server, the sender of the email message, and thedestination of the email message; test the behavior of the remote serverto generate a machine-originated response from the remote server inaccordance with the communications protocol to determine if the remoteserver is operating in accordance with the communications protocol, thetesting initiated during the communications session; and process thecommunications connection in response to whether the remote server isoperating in accordance with the communications protocol.
 14. Theapparatus of claim 13, wherein the communications protocol is the SimpleMail Transport Protocol.
 15. The apparatus of claim 13, wherein testingthe behavior includes sending at least one stimulus signal to the remoteserver.
 16. The apparatus of claim 15, wherein processing thecommunications connection includes accepting the message content if theremote server responds to the stimulus signal in the manner required bythe communications protocol.
 17. The apparatus of claim 15, wherein theat least one stimulus signal is one of a command and a reply, the formatand content of which are specified by the communications protocol. 18.The apparatus of claim 13, wherein testing the behavior includesterminating the communications connection.
 19. The apparatus of claim13, wherein testing the behavior of the remote server comprises: sendingto the remote server at least one session message, the format andcontent of which are specified by the communications protocol, whereinthe session message is configured to generate a machine-originatedresponse from the remote server in accordance with the communicationsprotocol; and determining whether the remote server responds to thesession message in accordance with the communications protocol.
 20. Acommunications system for processing an email message, comprising: acommunications network; a remote server connected to the communicationsnetwork and adapted to send the email message in accordance with acommunications protocol; and a receiving server connected to thecommunications network and adapted to exchange a plurality of sessionmessages containing session data and defining a communications sessionwith the remote server, the receiving server comprising: a connectionassessment module adapted to assess the session data; and a connectionbehavior testing module adapted to test the behavior of the remoteserver during the communications session to generate amachine-originated response from the remote server in accordance withthe communications protocol to determine if the remote server isoperating in accordance with the communications protocol.